Microprocessors (referred to herein simply as “processors”) execute instructions during their operation. It is very important to improve security during execution and preferably energy/power consumption should not significantly be affected by the solution.
Security is compromised when reengineering of program executables is possible. In addition, security of a solution such as an application intellectual property or algorithm is compromised when a processor can be physically microprobed and program information extracted without permission.
Program intellectual property can be re-engineered from binaries without requiring access to source codes. As reported by the Business Software Alliance, software piracy cost the software industry 11 billion dollars in 1998. Furthermore, an increasing number of tamper-resistant secure systems used in both military and commercial domains, e.g., smartcards, pay-TV, mobile phones, satellite systems, and weapon systems, can be attacked more easily once application semantics, including critical security algorithms and protocols, are re-engineered.
A key reason for many of these problems is that current microprocessors use a fixed Instruction Set Architecture (ISA) with predefined opcodes. Due to complexity, cost, and time-to-market issues related to developing proprietary microprocessors, most recent applications use commodity COTS components.
In software compiled for such systems, individual instruction opcodes as well as operands in binaries can be easily disassembled given that ISA documentation is widely available. Conventional systems can also be microprobed and these instructions extracted from the instruction memory systems or instruction buses.
Making the ISA reconfigurable (as a way to address these problems) is challenging, especially since a practically feasible solution would need to achieve this without significantly affecting chip area, performance and power consumption. Furthermore, it would be advantageous and practical if it could be retrofitted as add-on technology to commercially available microprocessor intellectual property (IP) cores from leading design houses such as ARM and MIPS. It should be backward compatible, e.g., capable of executing existing binaries to avoid losing existing software investments. Another critical aspect is migrating existing binaries to this new secure mode of execution without access to application source codes.
For a given processor there are typically many compilers available provided by many different vendors. These compilers have their own advantages and disadvantages. Moreover, when compiling an application many pieces of codes are added from precompiled libraries or hand-written assembly language.
Accordingly, if security-awareness is introduced at the executable-level, rather than at source code level, as in one embodiment of the present invention, by transforming the executable itself, significant practical advantages could be achieved. The goal would be to security-optimize executables that may have been fully optimized previously with a source-level compiler targeting a design aspect such as performance.